Support initial `modelVersion` in `Check Saved Objects` CI step by gsoldevila · Pull Request #248443 · elastic/kibana

gsoldevila · 2026-01-09T12:47:38Z

Summary

The PR updates the Check Saved Objects CI step logic to support the definition of the first (initial) modelVersion "1", by doing the following 2 things:

Not allowing mappings changes in the initial model version 10.1.0.
Updating the document migrator logic to consider 10.1.0 compatible with 0.0.0. Without this change, the CI check fails irremediably whenever we are introducing the first update (first modelVersion) for a given SO type. When stumbling upon such object after a rollback, the SOR APIs will not know how to handle it, and fail with an error of the form:

ERROR Error: Document "1281cd3a-293a-4415-ad71-64e8f79e8086" belongs to a more recent version of Kibana [10.1.0] when the last known version is [0.0.0].

elasticmachine · 2026-01-09T12:48:02Z

Pinging @elastic/kibana-core (Team:Core)

github-actions · 2026-01-09T12:49:19Z

🔍 Preview links for changed docs

docs/extend/saved-objects.md

gsoldevila · 2026-01-12T15:19:28Z

+    if (
+      // a SO type with no migrations: and only a single modelVersion: is, by definition,
+      // compatible, as we only allow schema definitions in the initial modelVersion.
+      (currentVersion !== '10.1.0' || latestVersion !== '0.0.0') &&


This is the first key change. I update the document_migrator logic to not fail in the 10.1.0 vs 0.0.0 scenario.

gsoldevila · 2026-01-12T15:20:04Z

+  if (mvs.length === 1 && mv.changeTypes.length) {
+    // Do NOT allow changes in the first (initial) modelVersion, only schema additions.
+    // This guarantees rollback safety towards previous versions.
+    throw new Error(
+      `❌ The new model version '${mv.version}' for SO type '${name}' is defining mappings' changes. For backwards-compatibility reasons, the initial model version can only include schema definitions.`
+    );
+  }


Second key change: Not allowing changes: [...] in the initial model version.

For these errors it might be nice to link to the docs

rudolf

Implementation looks good, left some nits for the docs

rudolf · 2026-01-12T15:35:45Z

+        // console.log('SNAPSHOT', JSON.stringify(ctx.to, null, 2));
+        // throw new Error('STOP');


Suggested change

// console.log('SNAPSHOT', JSON.stringify(ctx.to, null, 2));

// throw new Error('STOP');

rudolf · 2026-01-13T08:55:57Z

 };
 ```

+### Defining model versions for existing Saved Objects


I think it would be worth explaining here that you'll need to do two PR's one per serverless release. Otherwise they might commit their model version 1, CI passes, then commit model version 2 with changes and CI again complains.

I think we have a bit of a situation here. At the moment:

The pull_request pipeline is only testing against merge-base commit. Otherwise, there are multiple PRs that stem from branches that are older than current serverless release, which fail due to discrepancies in SO definitions. Good examples of this could be large PRs or feature branches. Imagine someone delivers a new modelVersion for a SO type, it gets released in Serverless. At that point, the CI check will fail for any branches that don't have that new modelVersion, as it will believe that the PRs are "deleting" the missing modelVersion. Well, not all PRs, only those that are making changes to SO definitions.

OTOH, the on_merge pipeline is testing against the current serverless release. The problem is that failures at this point are not very actionable.

Thus, for a scenario like the one you describe (aka someone creating 2 modelVersions within the same Serverless release), the 2nd modelVersion PR would pass pull_request CI and would fail in the on_merge pipeline.

We could test against current Serverless release in the pull_request pipeline, but that would mean that folks updating SO types would have to frequently rebase their PRs for CI to work.

Maybe we could run the check twice in the pull_request pipeline, once against the merge-base commit, and once against the current Serverless release SHA.

I think this kinda takes us to the 1 script vs 2 scripts discussion, in the sense that:

Some errors are caused by the SO type owner, and thus, actionable (e.g. those happening when testing against merge-base).

Other errors are not the users' fault, e.g. someone else introduced a SO type in Serverless that my branch does not have yet (happening when testing against current serverless release). The only action devs can take here is rebasing, or waiting for next serverless release, but these aren't changes that are inherent to the SO definitions.

I wonder if having two separate checks would make sense:

Leave current check as-is: Are MY SO types' changes valid?

Introduce a new check against current Serverless release SHA: Is my PR safe to merge, from the current Serverless release standpoint?

NB that if we don't check against merge-base, and we simply run the check against current Serverless release SHA, we can end up having errors in SO and not knowing whether they are caused by the users' changes (1) or by the PR branch divergence (2).

rudolf · 2026-01-13T08:57:24Z

+  if (mvs.length === 1 && mv.changeTypes.length) {
+    // Do NOT allow changes in the first (initial) modelVersion, only schema additions.
+    // This guarantees rollback safety towards previous versions.
+    throw new Error(
+      `❌ The new model version '${mv.version}' for SO type '${name}' is defining mappings' changes. For backwards-compatibility reasons, the initial model version can only include schema definitions.`
+    );
+  }


For these errors it might be nice to link to the docs

elasticmachine · 2026-01-13T16:19:04Z

💛 Build succeeded, but was flaky

Buildkite Build
Commit: b97a264

Failed CI Steps

Test Failures

[job] [logs] FTR Configs #123 / "before all" hook in "{root}"
[job] [logs] FTR Configs #119 / Endpoint plugin @ess @serverless @skipInServerlessMKI test metadata apis list endpoints GET route "before all" hook for "should return one entry for each host with default paging"

Metrics [docs]

Unknown metric groups

References to deprecated APIs

id	before	after	diff
`@kbn/check-saved-objects-cli`	2	3	+1

History

💛 Build #380893 was flaky db616f8
💔 Build #380361 failed 0f12979
💔 Build #380014 failed 25adc96
💔 Build #379618 failed 8b986eb
💔 Build #379558 failed 9ffbde2

…tic#248443) ## Summary Closes elastic#248231 The PR updates the `Check Saved Objects` CI step logic to support the definition of the first (initial) modelVersion `"1"`, by doing the following 2 things: * Not allowing mappings changes in the initial model version `10.1.0`. * Updating the document migrator logic to consider `10.1.0` compatible with `0.0.0`. Without this change, the CI check fails irremediably whenever we are introducing the first update (first _modelVersion_) for a given SO type. When stumbling upon such object after a rollback, the SOR APIs will not know how to handle it, and fail with an error of the form: ``` ERROR Error: Document "1281cd3a-293a-4415-ad71-64e8f79e8086" belongs to a more recent version of Kibana [10.1.0] when the last known version is [0.0.0]. ```

gsoldevila requested a review from a team as a code owner January 9, 2026 12:47

gsoldevila added Team:Core Platform Core services: plugins, logging, config, saved objects, http, ES client, i18n, etc t// release_note:skip Skip the PR/issue when compiling release notes backport:skip This PR does not require backporting labels Jan 9, 2026

gsoldevila force-pushed the no-migrations branch from 25adc96 to 0f96878 Compare January 12, 2026 15:02

gsoldevila changed the title ~~Test rollback only on rollback-testable types~~ Support initial modelVersion in Check Saved Objects CI step Jan 12, 2026

gsoldevila commented Jan 12, 2026

View reviewed changes

rudolf approved these changes Jan 13, 2026

View reviewed changes

gsoldevila added 3 commits January 13, 2026 13:22

Support initial modelVersion in CI check

5bbb2f1

Update task title

e51225a

Address PR feedback

b97a264

gsoldevila force-pushed the no-migrations branch from db616f8 to b97a264 Compare January 13, 2026 12:23

gsoldevila enabled auto-merge (squash) January 13, 2026 14:13

Misc enhancements

f8edfad

gsoldevila merged commit 1cc6859 into elastic:main Jan 13, 2026
13 checks passed

kibanamachine added the v9.4.0 label Jan 13, 2026

clintandrewhall mentioned this pull request Feb 10, 2026

Fix stale baseline_snapshot.json hashes in Check Saved Objects CI step #252435

Closed

2 tasks

		// console.log('SNAPSHOT', JSON.stringify(ctx.to, null, 2));
		// throw new Error('STOP');

Conversation

gsoldevila commented Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

elasticmachine commented Jan 9, 2026

Uh oh!

github-actions bot commented Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔍 Preview links for changed docs

Uh oh!

gsoldevila Jan 12, 2026

Choose a reason for hiding this comment

Uh oh!

gsoldevila Jan 12, 2026

Choose a reason for hiding this comment

Uh oh!

rudolf Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

rudolf left a comment

Choose a reason for hiding this comment

Uh oh!

rudolf Jan 12, 2026

Choose a reason for hiding this comment

Uh oh!

rudolf Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

gsoldevila Jan 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gsoldevila Jan 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rudolf Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

elasticmachine commented Jan 13, 2026

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

Metrics [docs]

References to deprecated APIs

History

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

gsoldevila commented Jan 9, 2026 •

edited

Loading

github-actions bot commented Jan 9, 2026 •

edited

Loading

gsoldevila Jan 13, 2026 •

edited

Loading

gsoldevila Jan 13, 2026 •

edited

Loading